It is becoming more and more common to run software applications in a shared hosting environment. For example, an application service provider (ASP) is a business that provides computer-based services to customers over a network. Those in the art often refer to software offered using an ASP model as on-demand software or software as a service (SaaS). The most limited sense of this business is that of providing access to a particular application program (such as medical billing) using a standard protocol such as HTTP. There is a growing market for hosted services where a hosting provider invites application developers or providers to submit and run their custom applications in an environment shared with other applications. This frees the application provider from the burden of purchasing and administering servers, and allows the hosting provider to realize economies of scale that come from managing many servers for hosted applications.
One type of application that is well suited for execution in a shared hosting environment is a model-based application. In the past computer software applications involved extensive programming knowledge and adaptation of low-level language functions to fit a particular business problem. For example, a user of a data management application may desire to add form processing functionality that was not included in the original application. Such a user could, optionally, pay for a systems integrator to come to the user's office and reconfigure or extend the application to include the desired functionality. Alternatively, if the user's company is large enough to have an IT department, the user could ask his or her IT manager to code in the additional functionality. This may, require a great deal of time from an already busy IT manager. As a last option, the user may opt to write the extension themselves, assuming the user has sufficient knowledge and available time to dedicate to such a task. Over time, users wanted to customize applications at lower cost and at a rate faster than software developers could provide changes.
To reduce the potential for errors and to simplify the process of creating applications related to business processes, software developers created model-based applications. Model-based applications use a data-driven approach to writing software, and typically include a model engine that executes model data created by the user. The model data allows the user to perform a variety of domain specific functions and to combine available functional components in various well-defined ways. Thus, a model engine provides a high level of customization without writing software code to unsophisticated application developers, at the expense of limiting functionality to those functions supported by the model engine. Generally, application developers use model engines for relatively simple things such as modeling workflows and corporate business policies. An example of a model-based application environment is Microsoft Access, in which users can define database tables, rules, and events in a data-driven environment.
In a shared hosting environment, the hosting provider limits the level of customization available to an application developer to reduce the potential of custom business logic to advertently or inadvertently exploit security holes on the shared system or to cause runaway loads on resources like memory, CPU, disk, and network bandwidth. A typical way that the industry has dealt with the potential for security/runaway resource consumption is by seriously limiting the level of customization of business logic that a hosted application can have. This limitation is simply not acceptable to many users, who cannot get the application functionality they want. Another way is to create a container (e.g., a J2EE container) or a virtual machine to sandbox the resources that custom code can use. However, this approach fails in a “multi-tenant” situation (where multiple user applications are run in the same environment), because there is a significant overhead and cost to creating a full, self-contained sandbox for every application. Also, different end-user application want to access some of the same resources, e.g. connectors to external data or a reference or master data that is common in the industry for a lot of applications.
A third way of handling security/runaway resource consumption is to statically inspect the application to attempt to verify that the application does not perform any undesirable actions. For model-based applications, the model provides visibility into what the application does. Thus, static checks can determine, for example, resources on which the model depends. The static checks may include limits of acceptable application behavior, such as thresholds that limit the number of times any one application can use a particular resource. The difficulty with static checks is that they can grow very large and conservative. Sometimes an application may want to perform a complex, but legitimate behavior that fails a static check. Static checks may also be unable to detect some types of bad behavior. For example, the application may respond unfavorably to data input by a user that is not available before executing the application. In addition, identifying new static checks is often a process of trial and error, where an administrator adds new checks as a hosting provider discovers new offending application behavior.